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Interception  of  software  interaction  for  the  purpose  of  introducing  additional  functionality  or  alternative  behavior  is  a  well- 
known  software  engineering  technique  that  has  been  used  successfully  for  various  reasons,  including  security.  Software  wrap¬ 
pers,  firewalls,  Web  proxies,  and  a  number  of  middleware  constructs  all  depend  on  interception  to  achieve  their  respective  secu¬ 
rity,  fault  tolerance,  interoperability,  or  load  balancing  objectives.  Web  proxies,  as  used  by  organisations  to  monitor  and  secure 
Web  traffic  into  and  out  of  their  internal  networks,  provide  another  important  example. 


As  more  and  more  interactions  (includ¬ 
ing  personal,  financial,  and  social) 
become  Web-based,  a  number  of  observa¬ 
tions  can  be  made.  First,  as  technology  ad¬ 
vances  and  public  awareness  of  Internet 
security  increases,  an  increasing  portion  of 
Web  traffic  is  likely  to  be  carried  by 
Hypertext  Transfer  Protocol  Secure 
(HTTPS).  Second,  while  that  will  provide 
a  level  of  end-to-end  security,  it  will  pre¬ 
sent  a  new  challenge  for  the  functions  and 
services  that  rely  on  inspecting  the  con¬ 
tent  of  Web  traffic.  Some  of  these  ser¬ 
vices  and  functions  will  concern  security, 
such  as  auditing  and  access  control.  The 
challenge  comes  from  two  directions:  (1) 
the  standard  Web  proxies  of  today  pass 
the  HTTPS  traffic  through,  and  (2)  Web 
proxies  are  somewhat  global  (aggregating 
Web  traffic  from  many  users  or  applica¬ 
tions)  and  agnostic  to  personalization  to 
an  individual  user’s  or  an  application’s 
context  and  requirement.  We  developed  a 
personal  proxy  that  is  capable  of  handling 
both  HTTP  and  HTTPS  traffic,  and 
demonstrated  its  use  in  tackling  the  threat 
of  phishing  attacks.  This  personal  proxy 
win  be  a  useful  tool  for  implementing 
functions  and  services  that  require  inspec¬ 
tion  of  Web  traffic  content. 

Introduction 

The  ability  to  intercept  normal  interaction 
between  application  components  enabled 
a  number  of  useful  functions  such  as 
monitoring  and  auditing,  adaptive  failover, 
load  balancing,  and  (last  but  not  least) 
enforcement  of  security  policies. 
Obviously,  the  need  for  many  of  these 
functions  is  already  felt  in  the  context  of 
Web-based  applications.  The  use  of  Web 
proxies  by  organizations  to  monitor  and 
protect  Web-based  applications  running 
within  their  networks,  the  use  of  load  bal¬ 
ancing  mechanisms  in  server  farms,  and 
handling  cross-domain  exchanges  are 
cases  in  point. 

A  number  of  interception-based  func¬ 
tions  require  deep  inspection  of  the  traffic, 
meaning  operations  that  need  to  access 


the  content  of  the  payload,  not  just  the 
HTTP  header  information.  Web  proxies 
can  do  this  job  perfectly  for  HTTP  traffic, 
but  not  for  HTTPS  traffic.  The  reason  is 
that  HTTPS  is  the  secure  version  of  the 
HTTP  protocol,  and  HTTPS  payloads  are 
encrypted  by  Transport  Layer  Security  and 
are  not  meant  to  be  inspected  or  modified 
by  interlopers  like  the  proxy. 

As  important  services  increasingly 
become  Web-enabled  and  as  the  task  of 
setting  up  HTTPS  becomes  routine,  we 

'We  developed  a 
personal  proxy  that  is 
capable  of  handling  both 
HTTP  and  HTTPS  traffic, 
and  demonstrated  its  use 
in  tackling  the  threat  of 
phishing  attacks/* 

expect  that  increasing  Web  traffic  will 
move  over  to  HTTPS  to  provide  a  level  of 
security  that  the  users  have  come  to 
expect  (e.g.,  the  padlock  sign  on  the 
browser).  This  gain  in  one  aspect  of  secu¬ 
rity  (i.e.,  site  authentication  and  defense 
against  confidentiality  and  integrity  attacks 
on  the  information  during  the  transit) 
makes  it  difficult  for  functions  that  require 
access  to  the  content,  such  as  auditing  and 
monitoring,  application  level  rate  limiting, 
application  level  adaptive  caching,  con¬ 
text-specific  failover  and  load  balancing, 
and  so  forth.  In  addition,  as  Web  services 
become  the  de-facto  mechanism  of  infor¬ 
mation  exchange,  proxies  are  likely  to  play 
a  key  role  in  handling  cross-domain  issues. 
For  example,  opening  HTTP  connection 
to  Web  sites  other  than  the  one  from 
which  the  current  Web  page  was  served  is 
usually  not  permitted  from  the  browser. 


but  the  application  may  need  to  interact 
with  services  from  other  Web  sites.  Using 
a  proxy  is  one  solution  that  is  often  used 
to  get  around  that  problem.  The  problem 
gets  more  complicated  if  different  ser¬ 
vices  are  at  different  security  levels.  If  that 
transaction  happens  over  HTTPS,  the 
standard  proxies  will  be  of  no  use  -  one 
must  use  a  proxy  like  ours  that  can  proxy 
HTTPS. 

The  global  and  impersonal  nature  of 
the  proxies  poses  another  challenge. 
Unlike  a  firewall  (that  deals  with  many 
protocols  including  HTTP  and  many 
ports  including  those  used  by  Web  ser¬ 
vices),  a  Web  proxy  is  narrowly  focused 
on  the  HTTP  traffic.  However,  like  a  fire¬ 
wall,  a  Web  proxy  covers  multiple  hosts, 
users,  and  applications  in  an  aggregate 
form.  The  wide  variety  of  Web  applica¬ 
tions  and  their  range  of  importance  and 
sensitivity  —  from  financial  transactions 
like  banking  and  shopping  to  social  inter¬ 
actions  over  Facebook,  Web-based  e- 
mail,  and  chat  —  will  demand  an  unfore¬ 
seen  level  of  personalization  or  applica¬ 
tion-specificity  in  monitoring,  auditing, 
access  control,  rate  limiting,  or  load  bal¬ 
ancing  solutions.  We  claim  that  the  aggre¬ 
gate  and  one-size-fits-all  nature  of  Web 
proxies  will  make  the  Proxy-based 
Solutions  situated  at  the  Internet  Service 
Provider  (ISP)  or  at  corporate  boundaries 
insufficient  and  less  acceptable. 

On  one  hand,  the  users  will  be  less 
comfortable  disclosing  their  personal 
preferences  and  requirements  to  the 
remote  proxy  that  they  do  not  own  and 
control  themselves.  While  understanding 
and  enforcement  of  the  policy  may  be  a 
daunting  task  for  some  users,  they  will 
still  demand  canned  policies  that  they  can 
turn  on.  Think  of  setting  your  browser’s 
security  settings,  but  different  settings  for 
Facebook  and  your  bank,  and  even  dif¬ 
ferent  settings  for  different  Facebook 
users  in  your  household  that  you  can  con¬ 
trol.  Then,  there  will  always  be  a  group  of 
technology-literate  users  questioning  the 
adequacy  of  protection  of  personal  data 
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and  the  quality  of  enforcement  offered  at 
the  remote  proxy.  On  the  other  hand, 
because  the  remote  proxy  aggregates 
traffic  flow  from  multiple  users  and 
applications,  they  are  ill-equipped  to 
enforce  policies  and  preferences  that  are 
highly  specialized  (personalized)  for  indi¬ 
vidual  applications  or  users  without 
mutual  interference. 

We  argue  that  we  need  a  personal  Web 
proxy  that  will  do  the  following: 

•  Be  situated  near  the  user  or  the  appli¬ 
cation  it  proxies  (it  is  even  possible  to 
have  dedicated  proxies  for  each  appli¬ 
cation),  and  is  controlled  by  the  user 
or  the  owner  of  the  application  it  is 
proxying. 

•  Enforce  the  user’s  or  the  application’s 
policies  and  personal  preferences  that 
can  be  easily  plugged  in. 

•  Be  able  to  inspect  HTTPS  traffic  with¬ 
out  compromising  the  security  gains 
contributed  by  the  HTTPS  protocol. 
The  envisioned  personal  proxy  is 

analogous  to  personal  firewalls:  As  per¬ 
sonal  firewalls  bring  firewall  capability 
near  to  the  user’s  host  from  the  network 
edge,  the  personal  proxy  will  also  push 
proxying  capability  from  the  network 
edge  closer  to  the  user  or  the  application. 
Furthermore,  the  personal  proxy  is  a 
valid  application  level  proxying  mecha¬ 
nism  that  can  be  easily  customized  for 
the  application  or  user  at  hand;  it  pro¬ 
vides  an  easy  way  to  introduce  additional 
application  or  user-specific  functionality 
in  the  HTTP/HTTPS  path. 

There  are  a  number  of  software  engi¬ 
neering  reasons  supporting  the  need  of  a 
separate  proxy,  as  opposed  to  embedding 
the  needed  additional  functions  into  the 
application  components  it  mediates 
between.  First,  the  proxy  adds  a  separate 
layer  of  protection  (another  process  to 
corrupt  —  a  crumple  zone,  if  you  wiU),  and 
provides  stronger  isolation  guarantees 
(defense  against  memory  corruption 
attacks)  and  increased  flexibility.  The  proxy 
is  less  complex  than  the  browser  that  has 
to  support  applications  ranging  from 
streaming  media  to  Java  applet,  and  pro¬ 
vides  a  smaller  attack  surface.  Since  the 
proxy  is  a  dedicated  process,  it  can  be  pro¬ 
tected  using  technologies  that  implement 
process  protection  domains,  such  as 
SELinux  [1]  or  Cisco  Security  Agent  [2]. 
Second,  a  personal  proxy  offers  a  good 
middle  ground  between  the  two  extremes, 
dealing  with  the  aggregate  of  interactions 
at  the  network  edge  or  modifying  each 
application.  A  browser  plugin-based 
implementation  will  not  be  able  to  control 
or  monitor  non-browser  applications  that 
may  use  HTTP  or  HTTPS  and  should  be 


subject  to  the  same  user-defined  policies 
and  preferences.  To  cover  this  situation, 
one  either  assumes  (somewhat  unrealisti¬ 
cally)  that  all  applications  interacting  over 
HTTP/HTTPS  use  the  browser  or  are 
forced  to  develop  similar  embedded  capa¬ 
bilities  for  each  of  those  non-browser 
applications.  Furthermore,  the  corporate 
or  ISP  proxy  may  not  be  able  to  enforce 
policies  of  individual  applications  and 
users  at  the  network  edge.  It  is  easier  to 
implement  user-  or  application-specific 
policies  and  behavior  into  a  personal  proxy 
that  runs  on  the  user’s  host  and,  using  fire¬ 
wall  rules,  mandate  that  the  only  way 
HTTP/HTTPS  traffic  gets  in  or  out  is 
through  the  proxy.  Third,  any  mechanism 
that  enables  flexible  and  customizable 
introduction  of  additional  behavior,  con¬ 
straint  enforcement,  and  monitoring  with¬ 
out  requiring  costly  (and  sometimes 


0  personalized  proxy 
can  be  used  to  protect 
the  user  from  divulging 
personal  information  to 
malicious  Web  sites 


impossible)  code  changes  in  the  original 
application  is  a  valuable  software  engineer¬ 
ing  asset.  The  personal  proxy  performs 
this  job  adequately.  Other  than  ensuring 
that  the  HTTP/HTTPS  traffic  flows 
through  it,  no  code  change  is  necessary  for 
the  applications  that  interact  through  it. 
Finally,  to  be  general  and  to  support  aU 
kinds  of  monitoring  and  inspection  use- 
cases,  the  additional  user-  or  application- 
specific  policies  and  behavior  must  be 
inserted  before  traffic  is  encrypted  with 
the  remote  site’s  key.  To  illustrate  the 
point,  note  that  Chinese  users  are  able  to 
bypass  governmental  scrutiny  enforced  at 
their  network  edge  by  interacting  with 
encrypting  proxies  outside  China.  While 
our  proposed  personal  proxies  are  con¬ 
trolled  by  the  user/ application  it  covers  (as 
opposed  to  any  government  agency),  there 
are  use-cases  (e.g.,  parental  control,  cross¬ 
domain  security  policy  enforcement) 
where  personal  proxies  provide  a  better 
solution  than  the  browser-embedded 
checks  or  proxies  at  the  edge. 

Under  Department  of  Homeland 
Security  (DHS)  funding,  we  have  devel¬ 
oped  a  customizable  Web  proxy  that  han¬ 
dles  both  HTTP  and  HTTPS  protocols. 
For  HTTPS,  the  proxy  works  by  establish¬ 
ing  two  System  Specification  Language 


(SSL)  connections:  one  between  the 
browser  and  the  proxy,  and  the  other 
between  the  proxy  and  the  remote  Web 
site.  The  customization  happens  by  con¬ 
figuring  the  proxy’s  chain  of  interceptors. 
The  proxy  can  be  placed  near  the  user,  on 
the  user’s  computer,  or  at  the  user’s  home 
router  box.  We  have  demonstrated  how 
such  a  personalized  proxy  can  be  used  to 
protect  the  user  from  divulging  personal 
information  to  malicious  Web  sites  (i.e., 
defense  against  phishing  attacks).  We  have 
started  investigating  other  uses  of  the 
proxy,  such  as  auditing  inter-agent  com¬ 
munication  in  a  semantic  Web  application 
so  that  the  recorded  interactions  can  be 
used  by  machine -learning  algorithms  that 
aim  to  learn  and  improve  how  the  agents 
achieve  their  tasks.  In  this  article,  we 
briefly  describe  the  architecture  and  oper¬ 
ation  of  this  personal  proxy;  a  detailed 
description  and  the  anti-phishing  applica¬ 
tion  appears  in  [3]. 

Architecture  of  the  Personal 
Proxy 

Figure  1  illustrates  the  design  of  the  per¬ 
sonal  proxy,  which  consists  of  four  main 
modules  that  are  implemented  on  top  of 
Jetty,  a  popular  open-source  Web  server 
written  in  Java  [4].  The  plugin  framework 
provides  a  means  for  integration  of  cus¬ 
tom  reactive  and  proactive  behavior.  In 
the  first  application  of  this  proxy,  all  anti¬ 
phishing  checks  were  implemented  as  a  set 
of  plugins  for  this  module.  A  plugin  can 
be  one  of  the  following  three  types, 
depending  on  its  role  in  the  overall  control 
flow  and  threading  logic: 

•  Data  plugins.  Each  data  plugin  is 
invoked  on  every  request  and  associat¬ 
ed  response.  A  data  plugin  is  used  for 
handling  the  header  and  payload  data 
based  on  a  specified  security  policy. 
For  example,  a  proxy  could  be  config¬ 
ured  to  record  all  or  selected  parts  of 
Web  traffic  as  part  of  a  parental  con¬ 
trol  policy.  Recordings  can  be  persisted 
securely  on  the  disk. 

•  Checks.  These  plugins  are  organized 
in  a  chain,  and  intercepted  requests 
flow  through  these  checks  like  a 
pipeline.  An  individual  check  exits  with 
either  a  break  or  a  continue.  A  continue 
indicates  that  the  request  goes  to  the 
next  stage,  possibly  with  some  addi¬ 
tional  metadata  tagged  to  it.  Breaks  can 
be  of  two  kinds:  A  negative  break  indi¬ 
cates  that  the  request  is  to  be  blocked, 
while  a  positive  break  indicates  that  the 
request  is  to  be  accepted.  In  either 
case,  a  break  implies  that  the  rest  of 
the  pipeline  stages  are  not  executed. 
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This  semantics  of  checks  is  amenable 
to  modular  implementation  and  inte¬ 
gration  of  security  policies. 

•  Probes.  In  contrast  to  checks  and  data 
plugins,  which  only  execute  reactively 
when  triggered  by  requests  or  respons¬ 
es,  probes  allow  us  to  embed  proactive 
behavior  into  the  proxy.  Probes  con¬ 
tain  dedicated  threads  that  trigger 
monitoring  functions  at  regular  config¬ 
urable  intervals.  The  probes  can  be 
configured  to  visit  specified  URLs  and 
scheduled  intervals  to  collect  data  that 
is  relevant  for  the  security  policy  con¬ 
text.  For  example,  in  the  case  of 
defending  against  phishing  attacks,  the 
probes  were  used  to  check  for  changes 
in  an  Internet  Protocol  address  or 
security  credential  of  the  banks  or 
financial  sites  registered  by  the  user. 
The  lower  part  of  Figure  I  displays  the 
remaining  three  modules.  The  modules  act 
as  access  paths  into  the  proxy.  The  HTTP 
Pro>gi  listens  on  a  configurable  network 
port  (e.g.,  8080)  for  incoming  HTTP 
requests,  and  dispatches  the  requests  to  a 
main  handler  (InterceptHandler),  which  in 
turn  makes  strategic  use  of  the  plugins. 
This  flow  is  similar  in  the  case  of  the 
HTTPS  Pro>cf,  except  that  it  listens  on  a 
different  network  port  (8443)  and  uses  a 
custom  extension  of  the  InterceptHandler 
(called  SslProxyHandler)  that  intercepts 
HTTPS  connect  requests  and  facilitates 
subsequent  interception  of  all  HTTPS 
requests  in  that  session.  The  third  access 
path,  HTTPS  Requests,  is  for  manage¬ 
ment  of  the  proxy  through  an  administra¬ 
tion  console.  Management  functions 
include  changing  the  order  of  plugins  and 
their  respective  importance  weights  as  well 
as  customization  of  user-specific  data. 
The  administrative  interface  is  optional 
for  out-of-the-box  deployment,  where  the 
proxy  is  preconfigured  and  preloaded  with 
appropriate  plugins  that  enforce  the 
desired  policy.  We  do  not  anticipate  that 
the  internal  details  are  important  for  most 
of  the  users  (beyond  pointing  their  appli¬ 
cations  or  browsers  to  the  proxy).  The 
users  who  write  and  package  custom  poli¬ 
cies  for  different  users  and  applications 
win  need  to  know  the  details  of  plugins.  A 
better  policy  interface,  supporting  a  gener¬ 
ation  of  plugins  (which  can  be  added  to 
the  proxy  by  editing  a  configuration  file) 
from  higher-level  policy  specification,  and 
a  better  way  to  inspect  the  policies  encod¬ 
ed  in  existing  plugins,  is  part  of  our  future 
work.  Once  this  policy  interface  is  in 
place,  these  users  will  also  be  shielded 
from  the  internal  details  and  complexities 
of  the  plugin  architecture.  If  the  internal 
details  change  because  of  evolution  of  the 


Figure  1:  Functional  Architecture  of  the  Personal  Pro^g 


Jetty  code  base/Web  services  specifica¬ 
tion,  only  the  policy  interface  implementa¬ 
tion  wiU  need  to  change. 

Placement  Options 

The  standard  deployment  of  the  proxy  is 
on  the  end  user’s  computer.  Although  this 
puts  a  small  load  on  the  Central 
Processing  Unit  (CPU),  memory,  and  disk 
resources  on  the  end  system,  it  has  the 
benefit  of  putting  the  proxy  under  direct 
control  of  the  end-user.  Our  understand¬ 
ing  is  that  end-users  feel  uncomfortable 
with  disclosing  personal  and  sensitive 
information  (preferences,  policies)  to 
external  parties,  but  are  more  amenable  to 
providing  this  information  to  local  com¬ 
ponents  as  long  as  it  doesn’t  leave  their 
machine.  Since  many  end-users  own 
either  a  wireless  or  DSL  router  and  since 
these  devices  already  ship  with  Web  serv¬ 
er  capabilities,  we  investigated  deploying 
the  proxy  on  a  Linksys  WRT54G  wireless 
router  running  OpenWrt  [5].  Another 
option  is  to  run  the  proxy  on  a  home 
router,  which  has  the  benefits  of 
increased  security  through  stronger  isola¬ 
tion  from  a  potentially  virus-infected 
desktop,  and  a  new  value-add  for  router 
manufacturers.  On  the  downside,  the  very 
limited  CPU  and  memory  resources  of 
the  home  routers,  especially  wireless 
routers,  significantly  lowers  the  perfor¬ 
mance  of  the  proxy. 

Insertion  Into  HTTP(S)  Flow 

Insertion  of  the  proxy  into  the  non- 
encrypted  HTTP  client-server  path  is 
straightforward  and  involves  changing  the 
client  application’s  proxy  settings  (e.g.. 


HTTP  Web  browser) .  To  prevent  an  attack¬ 
er  from  replacing  the  proxy  setting  to  a 
proxy  of  his  own,  and  to  ensure  that  any 
application  using  HTTP/HTTPS  is  subject 
to  the  security  policy  enforced  by  the  per¬ 
sonal  proxy,  firewall  rules  should  be  set  to 
only  allow  outgoing  Web  traffic  through 
the  personal  proxy.  For  intercepting 
encrypted  requests  from  client  application 
that  uses  HTTPS,  the  client  application’s 
(such  as  the  browser’s)  proxy  settings  are 
changed  accordingly  to  redirect  requests  to 
personal  proxy’s  HTTPS  port.  However, 
describing  how  appropriate  security  associ¬ 
ations  are  established  is  slightly  more 
involved  (see  Figure  2,  next  page). 

In  a  regular  use  case  without  any 
HTTPS  proxy,  SSL  relies  on  a  Public  Key 
Infrastructure  for  connection  establish¬ 
ment  [6].  Following  a  general  description 
of  the  SSL  protocol,  the  client  issues  a 
connection  request  to  the  server,  which 
the  server  acknowledges  with  a  response 
containing  a  certificate  signed  by  a  certifi¬ 
cation  authority  (CA) .  The  client  then  con¬ 
tinues  to  perform  a  set  of  checks  on  the 
server  certificate,  the  main  one  of  which  is 
to  verify  that  the  CA’s  signature  is  valid.  In 
most  cases,  SSL  transactions  essentially 
establish  a  unidirectional  trust  relationship 
between  the  browser  and  the  target  Web 
server  via  a  commonly  trusted  CA. 

With  the  proxy  in  the  mix,  the  proto¬ 
col  becomes  a  little  more  complex.  The 
proxy  takes  on  the  role  of  a  server  when 
communicating  with  the  browser  and  the 
role  of  a  browser  when  communicating 
with  the  target  Web  server.  This  requires 
the  proxy  to  dynamically  generate  X509 
certificates  for  each  Domain  Name 
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System  name  it  is  proxying^  certified  by  its 
own  CA’  (called  PB  CA  in  Figure  2). 
During  installation,  the  Web  browser’s 
(and  any  other  application’s  using  HTTPS) 
settings  are  configured  to  trust  signatures 
from  the  PB  CA.  As  a  result,  the  overall 
trust  relationship  between  browser  and 
target  Web  server  can  now  be  decom¬ 
posed  into  two  daisy-chained  relation¬ 
ships,  one  between  the  browser  to  the  per¬ 
sonal  proxy,  and  a  second  between  the 
personal  proxy  and  the  target  Web  server. 

Does  the  proxy  introduce  additional 
security  vulnerabilities  by  breaking  the 
end-to-end  encryption  between  browser 
and  Web  server?  The  answer  to  this  ques¬ 
tion  depends  on  the  relative  trustworthi¬ 
ness  of  the  proxy  compared  to  the  brows¬ 
er  and  target  Web  server  and  where  it  is 
deployed.  Consider  the  case  where  the 
user  does  not  use  a  personal  proxy,  but 
thinks  that  his  desktop  and  the  servers  he 
uses  are  more  secure  than  the  ISP  server 
through  which  he  uses  the  Internet.  The 
ISP  server  may  co-host  other  applications, 
and  if  it  does  not  have  the  latest  security 
patches  installed,  such  a  setup  would  sig¬ 
nificantly  lower  the  overall  security  of 
Web  transactions  flowing  through  it.  On 
the  other  hand,  if  the  personal  proxy  is 
co-located  with  the  Web  browser  on  the 
same  desktop,  we  would  expect  it  would 
be  more  difficult  for  attackers  to  subvert 
or  corrupt  the  Java-based  stand-alone 
proxy  process  (which  only  listens  on  local- 
host)  compared  to  a  C^--l-  Web  browser 
running  Javascript.  In  both  cases,  data  is 
never  sent  unencrypted  over  the  network, 
so  the  guarantees  provided  by  SSL  across 
host  boundaries  are  not  affected. 

Performance  Overhead 

Introduction  of  a  clearly  noticeable  delay 
presents  increased  resistance  to  adoption 


of  the  new  technology.  To  minimize  per¬ 
formance  impact,  we  implemented  the 
proxy  on  top  of  the  high  performance 
Jetty  Web  server  and  implemented  various 
optimizations  in  the  SSL  proxy  architec¬ 
ture  to  keep  request  latencies  (i.e.,  elapsed 
time  between  a  request  and  its  response) 
within  user  acceptable  levels.  In  this  sec¬ 
tion,  we  use  overhead  to  mean  the  increase 
in  request  latency  due  to  interception  of 
HTTPS  traffic  by  the  proxy. 

We  measured  the  overhead  in  a  lab  set¬ 
ting  by  visiting  HTTPS  sites  without  the 
proxy  and  with  the  proxy  configured  with 
a  number  of  anti-phishing  checks.  The 
mean  time  to  load  the  visited  pages 
through  the  proxy  was  twice  the  mean 
time  to  load  the  same  pages  without  the 
proxy  (excluding  any  user  interaction  like 
typing  a  password  for  both  cases). 
However,  the  variance  of  load  time  was 
comparable  to  the  mean  (not  surprising 
because  we  were  visiting  sites  on  the 
Internet),  and  even  an  overhead  of  rough¬ 
ly  100  percent  was  not  distinguishable 
from  the  noise  (as  noted  by  external  field 
testers,  the  delay  introduced  by  the  proxy 
does  not  noticeably  impact  the  user  Web 
surfing  experience).  Much  of  this  over¬ 
head  can  be  attributed  to  crypto  opera¬ 
tions  and  session  multiplexing  performed 
in  Java.  We  expect  the  plumbing  overhead 
to  stay  independent  of  the  policy  checks 
enforced  by  the  proxy. 

We  also  compared  the  round-trip 
latencies  between  an  auditing  configura¬ 
tion  (when  the  proxy  is  simply  record¬ 
ing)  and  a  policy  enforcing  configuration 
(loaded  with  anti-phishing  checks).  We 
found  that  the  two  distributions  are  not 
significantly  different  as  their  inter-quar- 
tile  ranges  overlap  to  a  large  extent 
(from  200  to  1,500  milliseconds  [ms]) 
and  both  distributions  have  a  large  num¬ 
ber  of  oudiers  (some  even  greater  than 


Figure  2:  Personal  Proxy  as  a  Trusted  Middleman 
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50,000  ms).  We  suspect  that  available 
network  bandwidth  to  the  external  Web 
sites  together  with  available  CPU 
resources  of  those  sites  have  the  biggest 
impact  on  round  trip  latencies,  which  is 
why  the  distributions  looked  similar. 

Related  Work 

Various  HTTP  and  HTTPS  proxy  imple¬ 
mentations  exist  for  debugging  purposes 
(Burp  proxy  [7],  Charles  proxy  [8])  and 
Web  filtering  (WebCleaner  [9],  Privoxy 
[10]).  There  are  also  a  number  of  com¬ 
mercial  network  layer  tools  (e.g,  eSafe’s 
Web  Threat  Analyzer  [11],  McAfee 
IntruShield  [12])  that  can  inspect  Web 
traffic,  including  HTTPS  that  work  at  the 
enterprise  layer.  In  many  cases,  these  are 
geared  for  regulatory  and  auditing  compli¬ 
ance,  the  DHS-funded  research  focused 
on  transparent  inspection  of  SSL  traffic 
exclusively  for  regulatory  purpose. 
However,  we  were  unable  to  find  a  proxy 
that  could  be  used  as  a  general  purpose 
middleware  construct  for  customized  user 
and  application-specific  policies. 

Conclusion 

We  have  been  developing  advanced  mid¬ 
dleware  technologies  that  enable  adaptive 
behavior,  quality  of  service  (QoS)  man¬ 
agement  and  QoS-based  adaptive  behav¬ 
ior  in  distributed  systems  over  the  past 
several  years  [13].  In  doing  so,  we  have 
developed  middleware  constructs  for  han¬ 
dling  different  styles  of  distributed  inter¬ 
action  (e.g,  distributed  objects,  pubUsh- 
subscribe,  group  communication)  over  a 
number  of  protocols  (e.g,  socket-based. 
Common  Object  Request  Broker  Archi¬ 
tecture  or  Remote  Method  Invocation). 
The  present  work  involving  HTTP  and 
HTTPS  interception  complements  that 
line  of  successful  work,  and  enables  us  to 
introduce  advanced  middleware  capability 
to  distributed  systems  that  use  these  pro¬ 
tocols.  The  concept  of  a  personal  proxy 
has  the  potential  to  fill  an  important  and 
emerging  gap  in  the  current  Web-based 
systems  architecture. 

However,  as  noted  earlier,  the  person¬ 
al  proxy  is  still  in  its  early  stages  —  we  only 
have  a  prototype  implementation  that  is 
demonstrated  with  anti-phishing  checks, 
and  have  just  begun  exploring  its  use  in 
other  contexts. 

A  number  of  software  engineering  and 
usability  issues  also  need  additional  work, 
including  an  easy  way  to  inspect  enforced 
policies  and  the  ability  to  define  policies  at 
a  higher  level  of  abstraction  that  can  be 
automatically  translated  into  executable 
code  that  can  be  integrated  into  the  plug¬ 


in  framework.  These  are  the  next  steps  we 

hope  to  tackle. ♦ 
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1 .  This  work  was  supported  by  the  DHS 
Advanced  Research  Projects  Agency 
under  contract  number  NBCHC050096. 

2.  To  increase  generation  performance, 
key  pairs  can  be  reused  across  certi¬ 
ficates. 

3.  Alternatively,  the  PB  CA  can  be  signed 
by  a  common  root  CA. 
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